Is the problem that injectDefaultVars has to return synchronously?
Or could you fetch the saved object here?

I do believe it has to be synchronous, but regardless: the issue here is that the value of apm_oss.transactionIndices could have changed via the UI Indices settings UI since it was injected here during plugin startup. So I'll have to make an API call for it whenever the client requires this index.

Ahh yes ofc. Instead of making a separate endpoint for this, can you call the existing endpoint that exposes the ui indices?

Is it necessary to say it comes from a hook? I got a little confused with that name at first.

Naming conflicts with the function argument to useFetcher.

What about using calApmApi from the hook everywhere?

  const callApmApi = useCallApmApi();

  const { data = [], status, refetch } = useFetcher(
   () => callApmApi({ pathname: `/api/apm/settings/ui-indices` }),
    [callApmApi]
  );

I think it's confusing having two different instances of it.

Why refetch on Cancel?

cancel behavior resets the values to whatever was previously saved, which can be accomplished by calling refetch. Alternatively i could add more to the component state to store the initial values, and set that when cancel is clicked.

Ah, makes sense. Seems simpler to just refetch 👍

Why preservePreviousData: false?

Do these need translations?

Naming conflicts with the function argument to useFetcher.

nit: I think it's generally more robust to initially create an empty object for the form values, and then merge them synchronously inside of the render function. This explicitly prioritizes user changes over network data, and can help eliminate situations where the user will lose data due to a race condition

Translation?

Further down, I thought configuration was an object, but it is a string, so maybe something like configurationName would be helpful.

I'm having a bit of a hard time understanding what this function does. I guess it's getting all the values from apm_oss? Would it be better to just explicitly define that here? Seems like deepValues is not being used either? e.g.:

return Object.values(apmIndices.apm_oss);

the purpose of flatValues as opposed to Object.values(apmIndices.apm_oss); is to keep getApmIndicesList generic. If we add a new index configuration, e.g. xpack.apm.ui.someNewIndex, then it gets included in getApmIndicesList without having to change that function. I open to changing this, but that was my original motivation.

perhaps an enum would limit the amount of times we have to (re)define this?

Is it possible to use this function for getApmIndices as well? Or are there subtle differences that I'm missing?

the difference is that getApmIndices returns the resolved static/runtime indices, while this function returns more of a breakdown of the resolution, which informs the UI how to render the settings page. i.e. getApmIndices could be derived from the result of this function, not the other way around.

I've seen this a couple of times now as well, should we use a constant for this?

out of curiosity, should we always intercept server errors and log them explicitly, or does that happen automatically?

Your right, it's not necessary here. I'll remove these.

I'm not following this. Why would getApmIndices not return unique values? Or rather: is it important whether they are unique?

Ahh, now I see. This is specifically for addFilterForLegacyData? I found getApmIndicesList a little confusing. Perhaps you can call Object.values(await getApmIndices(server)) from getParamsForSearchRequest and delete getApmIndicesList because I don't see the necessity for removing duplicates.

There is both getApmIndicesList and listUiIndices. That seems a little ambiguous.

This is the nice thing about having identical structures in the config and saved object. It's straightforward to merge them 👍

I forget: did we settle on whether runtime index configuration should be per user, or across all users? And whether anyone should be able to change it or only admins?

Instead of filtering on the backend, what about simply returning all config options:

return await getApmIndices(server);

It's not a big response, so the savings ar negligible.

This way you can get rid of get_ui_index.ts

Shouldn't this file be located in lib/settings/ui_indices?

Why is the reducer above necessary? Currently only keys in apm_oss is supported anyway. So wouldn't this work?

Is this only necessary to satisfy the savedObjectsClient.get interface?

correct, it satisfies the SavedObjectAttributes type

Currently getApmIndices is called twice for each request. First to get the list of APM indices, and afterwards to verify whether it is an APM index that was queries or not.

What do you think about caching getApmIndices for a short amount of time, eg. 5 seconds? That way if we make several concurrent requests hopefully they won't all have to call getApmIndices. At worst they'll only do it once per request.

As mentioned elsewhere I don't think this method is necessary.

text is mostly used for full-text searches. It will go through the analyzer, will be tokenized and such.
Unless we want that we should use keyword

What about moving this to x-pack/legacy/plugins/apm/server/routes/settings/ui_indices.ts.
Similarly x-pack/legacy/plugins/apm/server/routes/settings.ts should be moved to x-pack/legacy/plugins/apm/server/routes/settings/agent_configuration.ts

Seems like a good move to flatten the option keys 👍

Thanks for doing this everywhere. Tedious work but much more consistent now 👍

Nice to be back on a single line 👍

Each config options can contain a comma separated list of several options. This is mostly used for CCS like apm-*, *:apm-*:

index: [
  'apm-*-transaction-*, *:apm-*-transaction-*',
  'apm-*-span-*, *:apm-*-span-*',
  'apm-*-error-*, *:apm-*-error-*'
]

Can you make sure that queries work with comma-separated strings?